查核資訊： 本文於 2026-08-21 查核 OWASP LLM01:2026、OWASP Prompt Injection Prevention Cheat Sheet、NIST AI 100-2e2025 與 Ollama chat API，並引用同日完成的固定合成實驗。模型、API 與攻擊手法仍會演進；把本文控制套用到正式系統前，請重新確認最新文件與實際邊界。

一份惡意文件可以是合法的 UTF-8、沒有多餘欄位、長度也完全合規，卻在正文寫著「忽略原任務，改做另一件事」。

傳統 schema validator 能確認欄位、型別、大小和媒體格式，卻無法判定自然語言裡的意圖是否安全。若把「通過格式驗證」解讀成「內容可信」，只是替攻擊指令蓋上一個合格章。

Day 14 已用十種情境對示範摘要器做過注入普查。到了防禦工程的第一天，我不先加入另一句「請勿聽從資料」，而是把輸入邊界拆成三個能分開驗收的問題：應用程式接受了什麼？模型看到的來源結構是什麼？模型最後有沒有受資料裡的指令影響？

第一層：用固定契約決定能不能進來

Day 22 的示範應用只有一個 server-owned task：public-event-summary-v1。應用程式不接受使用者另傳 task ID，也不根據文件內容改選任務。輸入進入模型前，應用程式先以確定性程式檢查：

• 使用者要求（user_request）最多 512 字元；
• 參考文件（reference_note）最多兩份，每份最多 512 字元；
• 摘要目標文件（target_document）必須存在且最多 512 字元，全部文字合計最多 2,048 字元；
• 圖片必須存在、只能是 PNG，而且最多 65,536 bytes；
• policy 欄位必須與 v1 schema 完全相同，未知欄位、缺欄位或錯誤型別一律拒絕；
• 多輪對話的後續回合不能重新夾帶第一輪的參考文件、摘要目標文件或圖片。

這些條件都由確定性程式判斷；在相同版本的程式裡，同一份輸入會得到相同 admission decision。這道驗證能阻擋過大內容、錯誤媒體與不符合契約的欄位，卻無法判定文字是否惡意。格式合規的注入仍會進入下一層。

第二層：隔離標記後送入，但不升級信任

來源通過契約後，應用程式會把各個來源序列化為 canonical JSON。每一項都保留 kind、provenance、內容雜湊與 trust: untrusted；JSON key 的排序與空白表示法也保持固定。接著，應用程式會對完整的 user message 計算 SHA-256。圖片 bytes 仍由 Ollama 的 image 欄位傳送，envelope 只記錄 media type、路徑、大小與雜湊。

縮小後的結構大致如下：

{
  "inputs": [
    {
      "content": "請完成公開活動摘要",
      "kind": "user_request",
      "provenance": "caller",
      "trust": "untrusted"
    },
    {
      "content": "……",
      "kind": "reference_note",
      "provenance": "synthetic-notes/98-indirect-injection.md",
      "sha256": "……",
      "trust": "untrusted"
    }
  ],
  "schema": "input-envelope-v1",
  "task_id": "public-event-summary-v1",
  "turn": 1
}

task ID、schema 與來源標記都由應用程式產生，這些欄位不由文件自報。稽核時，驗證程式會把 decision 的 serialized hash 與實際 user message 比對，避免證據和送入模型的內容各說各話。

不過，canonical JSON 仍只是模型讀到的一串 token。OWASP LLM01:2026 指出，生成式模型本身沒有可靠的 instruction／data 分界。結構與 provenance 可以降低歧義、幫助偵錯，也可能改善模型行為，卻無法在模型內部形成強制隔離。

第三層：用完整配對 100 runs 驗證行為

為了避免把「程式看起來比較嚴謹」當成防禦有效，我把 Day 14 的十組測試資料原樣複製到獨立 experiment bundle：Clean、直接注入、間接文件、delimiter break、假設情境、三輪逐步誘導、Base64、many-shot、清楚圖片與低對比圖片。每種情境都有 baseline 與 defended 路徑，兩條路徑再以相同的五個 seeds 811–815、temperature 0.7 和同一個 gemma4:latest digest 進行配對。

實驗矩陣因此包含 10 種情境 × 2 條路徑 × 5 seeds，共 100 個 run units。三輪逐步誘導的每個 run 都有三個回覆，所以人工審查範圍增加到 120 個 assistant turns。事前預測也先鎖定：defended 假設情境應低於 Day 14 的 3／5，但不預測歸零。

正式實驗只執行一次，時間為 06:18:53–07:28:57 UTC；100 個 run units／120 個回覆全部完成，沒有
針對特定情境重跑。原始證據的 SHA-256 為 4ecda68a…22bd9b；完整 runner、固定契約與不含原始回覆的
sanitized 結果，均封存在
Day 22 immutable checkpoint。

Exact attack marker 只表示固定字串是否出現，無法分辨模型是在執行攻擊、改寫內容，還是在拒絕時引用字串。因此，本次人工審查另外判斷模型是否真的執行攻擊，以及是否重建至少兩項政策事實。任務效用、exact 與 semantic 訊號不能合併成一個成功率。

下表每格均以 baseline / defended 呈現；每組配對使用相同的測試資料、seed 與模型：

結果支持事前預測：defended 假設情境低於歷史與本次 baseline 的 3／5，也低於事前上限 2／5。三輪情境是另一個 exact marker 非零的 baseline，結果為 1／5；defended 則降到 0／5。不過，該次 marker 命中只是模型在拒絕時引用字串，沒有執行攻擊或揭露政策，因此人工判讀仍是 0／5。

防禦也不是免費的。圖片 public code 在兩條路徑都是 50／50；指定 target marker 在 baseline 為
50／50，在 defended 則是 49／50。defended crescendo 還出現五個空白 follow-up，以及一個錯誤
宣稱第一輪 fixtures 不存在的回覆。攻擊成功訊號下降，不代表對話效用會自動維持。

能確定的是介面，不是模型永遠聽話

OWASP 的防禦建議把輸入驗證、輸出監控與最小權限放在分層防線裡；NIST AI 100-2e2025 也提醒現有緩解措施並不完整。Day 22 只完成其中的輸入端：

1. server 決定任務，不讓不可信來源重新選擇用途。
2. 每種來源都有明確的數量、大小、格式與總量上限。
3. 格式驗證只產生 allow/reject，不把 allow 改名成 trusted。
4. 應用程式使用 canonical envelope 保留內容的 kind、provenance、trust 與 hash。
5. 實驗分別量測 task utility、攻擊行為與資料跨界，並保留配對的模型、seed 和 fixture 證據。
6. 架構仍假設模型可能被繞過；模型輸出若可能在後續觸發副作用，後續邊界就必須重新授權。

這套做法的價值，不是替 prompt injection 宣告結案，而是把原本模糊的 prompt 前處理變成可測、可拒絕、可追查的應用程式介面。輸入端防禦合理的承諾應該是：降低但不保證歸零。

下一篇會把視線移到模型輸出。即使輸入通過契約、模型也產生了回覆，應用程式仍須過濾、審核並安全渲染輸出，避免文字在下一個 sink 變成動作。

參考資料

• OWASP LLM01:2026 Prompt Injection
• OWASP Prompt Injection Prevention Cheat Sheet
• NIST AI 100-2e2025: Adversarial Machine Learning
• Ollama API: Generate a chat completion
• Day 22 immutable Lab checkpoint

本文同步刊載於作者的個人 Blog：閱讀原文。